test: add renamed equity ticker scaffold test - #35

Description

Adds ReturnsCurrentTickerAfterEquityTickerChange to the template symbol mapper tests. Equity tickers change over the life of a SID (e.g. GOOCV -> GOOG), and a Symbol can still carry the old ticker in Value — for example an order reloaded from disk, whose Value defaults to the SID permtick. Several brokerage plugins sent that old ticker to the broker because the mapper read Symbol.Value / Symbol.Underlying.Value instead of resolving with SecurityIdentifier.Ticker(symbol, DateTime.UtcNow).

The scaffold test bakes this check into every new brokerage: a Symbol carrying the historical permtick must map to the current ticker, for the equity and for the equity option root. The assertions use Contains, so they hold for any brokerage symbol format (plain ticker, OSI option string, ticker with market suffix). The implementer only replaces the ISymbolMapper symbolMapper = null; TODO line with the plugin's mapper. The fixture keeps its class-level Ignore until the plugin implements it.

Related PR(s)

The bug and fix pattern this test guards against:

• Lean.Brokerages.CharlesSchwab#95
• Lean.Brokerages.WeBull#7, Lean.Brokerages.Alpaca#70, Lean.Brokerages.Fix.Bloomberg#8, Lean.Brokerages.Eze#28, Lean.Brokerages.TerminalLink#123

Related Issue

N/A

Motivation and Context

The same renamed-equity ticker bug appeared independently in six brokerage plugins. New plugins scaffolded from this template should start with the test that catches it.

Requires Documentation Change

No

How Has This Been Tested?

The test project compiles and the fixture is skipped as before (class-level Ignore until the plugin is implemented). The same test cases (GOOCV -> GOOG, GOOG -> GOOGL) run green in the CharlesSchwab, WeBull, Eze, TerminalLink, and Fix.Bloomberg plugins.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>